Distributed applications are typically deployed in application server frameworks that exploit a specific distributed application architecture. Examples of such architectures are CORBA, J2EE, and .NET. An application server framework based on a specific architecture might typically be implemented using a specific set of technologies and be predisposed to supporting applications designed for the architecture supported by the application server. For example, a J2EE server is typically written for Java-based applications. Further foreign (or legacy) applications, for example databases, that were not designed with this architecture in mind can often be accessed through adaptive layers. For example, J2EE applications can access relational databases, such as DB2, through a JDBC adaptive layer. Adaptive layers like JDBC are good solutions for pervasive applications such as relational databases.
However, some legacy applications can be very specialised such that providing an adaptive layer to access them from a server framework based on a very different specific architecture can be expensive. For example, an application in a ‘C’-based system which has a complex relationship with a relational database through its ‘C’ interface could be very difficult to deploy in the Java J2EE environment. One of the problems is that the middleware infrastructure to support distributed transactions is embodied by the J2EE application server in a Java virtual machine, whereas the resource access, which needs to occur under transaction control, happens in the ‘C’-based legacy system.
Relational databases can typically support external co-ordination, for example, through either a ‘C’-based system using XA functions or through a Java based system, such as provided by a J2EE server, using a Java XAResource interface. In such systems for transactional access of data resources there needs to be an association between an application's connection to the database on which data resource exists and the distributed transaction under which the data is accessed. As a result there exists a problem in that if a transaction manager which provides transaction support is only available in the Java based environment and the data resource access occurs in the ‘C’-based environment, where the JVM based transaction manager is not available making the association very difficult.
Further, the problem is more complicated if access to the same data resource is required from both a Java and “C” based system within a single transaction because this results in a need to share locks. Whilst the XA specification describes this for a “tightly-coupled” transaction in which two threads of the same process access the same data resources within a single transaction based, this is based on a single process and a high degree of co-operation between the threads. However this does not provide for sharing rescues in a single transaction across disparate systems where such co-operation difficult, for example where one system is a Java based environment and another system is a ‘C’-based environment.
A possible solution to these problems is to provide a ‘C’-based transaction manager (TM) to co-ordinate the C updates and have this ‘C’-based TM subordinate to the Java TM. But this requires the significant overhead of providing a TM for the ‘C’-based system which employs a different architecture from the J2EE server—for example a CORBA server which supports Object Transaction Service (OTS). Providing a TM which supports multiple middleware architectures has a cost in terms of both skills and maintenance and may not be acceptable.